What about "updated" users?

Actually I wonder if the connected_users of the _websocket_server is even used.
I copied that code from the previous message handler, but I don't know if we need that function.
If we keep it, we should indeed handle the "updated" users (removing the former name and add the new one).

If we keep it, we should indeed handle the "updated" users (removing the former name and add the new one).

Thinking again about that, we don't have the previous name, the changes contain only the client ids.
We should rebuild the full list from the global awareness when a user is updated, because we don't know if the user name has been updated.

Right, the goal of this code was to check in the backend that the awareness information from the frontend is correct. For instance, we don't want a student to take the user name of the teacher. That's why there is this skip variable that was supposed to filter out an awareness message, but this was never put to actual use.
I'm wondering how we can filter out a message with your changes though?

I don't know if we can filter out a message with the current information we have.
For example when you reload the page, it adds a new client id with the same user information. The old client id is removed in a second step (probably when a client has a lack of update from it ?).
The same user is duplicated over a period of time, with 2 different client IDs. If we allow this behavior, I don't know how we can filter out someone trying to cheat.

The following image shows some logs when a remote client reloads the page. When a change is received, the change and the current users in the awareness are printed.

The backend is the authority for user identities, and the frontend can get its identity at /api/me, so we should be able to check that they match.

I agree that it's out of scope for this PR, but I'm wondering if we still get the possibility to discard an awareness update?